|
![](/i/fill.gif) |
Gilles Tran wrote:
> I still don't understand how that would protect the owners of the search
> engine from litigation.
It probably wouldn't, but it might help. Just like it helps having P2P
instead of centralized warez sites helps prevent the copyright owners from
taking stuff offline.
> If a user can get a pointer to get some illegal
> content, the party that provided the pointer can be found liable,
Well, sure. The owners would have to not blatantly acknowledge that they're
helping distribute copyrighted files.
The benefit is that if someone comes and confiscates your servers, there's
zero information on the server that would say any of the links are to
copyrighted material. It would be like a site full of tinyurl URLs getting
sued for pointing at copyrighted information.
> least if they didn't show due diligence in cleaning up their
> index/tracker/whatever.
And how would you do that, without downloading every torrent posted to your
own server without
> How would your system work in practice (from a
> user point of view) ?
I'm guessing you could make it look a lot like bittorrent does right now.
For example, the protocol could be changed that if you include a file called
README or MANIFEST or some such, that file gets hashed into a bloom filter
and the result is tacked onto the .torrent file. (You'd probably have to
take the file names *out* of the .torrent file and put it into a file inside
the torrent data itself.)
When you wanted to do a search, you put in your search terms, your *client*
generates a bloom filter, sends it to the search server, which looks thru
its torrents to find matching ones, and sends the matching torrents back to
you. The client would then connect to each such torrent, download the
README/MANIFEST/whatever file, make sure the bloom match worked, and if so,
show it to you and ask if you want to download the rest of the stream.
The server, in the meantime, shouldn't return too many search results, to
prevent attackers from doing offline searches of the bloom filters. I.e.,
the server needs to make sure there are significant amounts of search text
(as in, enough bits set to imply s sufficiently long search string that
you're unlikely to get too many false positives) in the incoming filters.
Of course it's not going to be complete protection. It's another layer of
plausible deniability just like DHT is. The only good solution is a good
distributed search algorithm. Bloom filters just make it possible to do a
full-text search without any party knowing what you're searching in or what
you're searching for.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
![](/i/fill.gif) |